[Draft] Fix DP userspace crashes and memory-allocation failures for compressed playback on PTL - #11181

llext_manager_add_domain()/llext_manager_rm_domain() crashed
(llext_manager_mod_find() dereferencing an invalid ctx) when called for
a native (non-LLEXT) module scheduled on the DP+userspace-application
path. lib_id == 0 is reserved and never populated by a loaded library,
but was not guarded against.

Skip the LLEXT domain add/remove entirely when
LIB_MANAGER_GET_LIB_ID(module_id) == 0.

llext_manager_mod_find() also needs its own guard against ctx->n_mod
== 0: that's reachable for a genuine (non-NULL) library context, e.g.
before its module segments are registered, and without the check the
i == 0 case in the loop below reads ctx->mod[-1], out of bounds.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

cfg->ext_data points to a stack variable in module_adapter_new_ext(),
valid only synchronously - but SOF_IPC4_MOD_INIT_INSTANCE runs
asynchronously in the DP userspace thread, so ops->init() ended up
reading a stale pointer into a different thread's stack (privilege
violation, not a simple NULL deref).

Add ext_data to union scheduler_dp_thread_ipc_param, flatten it by
value in ipc_thread_flatten() (copying it while still on the calling
thread, before the pointer goes stale), and repoint
pmod->priv.cfg.ext_data at the flattened copy in
ipc_thread_unflatten_run() before calling ops->init(), clearing it
again afterwards to match the existing "not valid outside init()"
convention.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

cadence_api_table[] is a compile-time-constant lookup table (codec id
-> function pointer), populated once at link time and never written to
at runtime, but declared without const - placing it in .data. Zephyr's
Xtensa MMU marks .text/.rodata XTENSA_MMU_MAP_SHARED (globally
accessible from every memory domain) but not .data, so the DP
userspace thread's restricted domain couldn't reach it, causing a
privilege-violation crash on the very first codec dispatch.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

z_impl_mod_balloc_align() called sof_heap_alloc(res->alloc->heap, ...)
directly, bypassing the module's vregion entirely - unlike
mod_alloc_ext(), which correctly checks vreg first via
sof_ctx_alloc(). For DP/vregion-scoped modules res->alloc->heap is
NULL, so this silently fell through to the global heap/rballoc(),
handing back memory outside the DP thread's memory domain. This is
what made cd->self (a codec's own library object, allocated via
mod_balloc()) unreachable from inside the DP userspace thread.

Route through sof_ctx_alloc(res->alloc, ...) like mod_alloc_ext()
already does.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

DP components cannot access pipeline objects. Move the End Of Stream
flag to the component type.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

struct vregion is created on the DP module's own core (via
vregion_create(), invoked from module_adapter_dp_heap_new()) but is
read and written from other cores too - e.g. buffer_new() on the IPC
core dereferences vr->lifetime.{base,size,used,ptr} for every buffer
connecting to that DP module.

The struct was allocated with plain rmalloc(0, ...), i.e. ordinary
cached memory. Writes made by the creating core can stay in that
core's D-cache indefinitely, invisible to any other core reading the
same physical address, since nothing ever flushes them out. In
practice this showed up as buffer_new() on the IPC core intermittently
seeing an all-zero vregion (base/size/used all 0), so any allocation
failed as "lifetime alloc failed ... free 0" even though the vregion
had over 100KB genuinely free - the metadata core 0 read simply hadn't
propagated from core 1's cache yet.

Allocate the vregion metadata with SOF_MEM_FLAG_KERNEL |
SOF_MEM_FLAG_COHERENT instead, matching the existing pattern used for
other cross-core shared structures in this codebase (e.g. vpage.c,
regions_mm.c). This returns an uncached alias, so every core sees
writes immediately without needing explicit cache maintenance.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>